Terima kasih untuk context yang sangat lengkap, Ricky. Sebelum saya memberikan rekomendasi project yang spesifik, ada beberapa hal yang perlu saya klarifikasi untuk memastikan rekomendasi yang tepat:

Pertanyaan Klarifikasi:

1. Durasi Enrichment Project – Berapa lama timeline project ini? (1 semester, 2 semester, atau durasi tertentu?)
2. Ekspektasi Output dari Prof. Widodo – Apakah ada format deliverable yang sudah ditentukan? (paper publikasi, prototype, technical report, atau kombinasi?)
3. Fokus Prioritas – Antara AI dan Robotika, mana yang lebih ingin kamu dalami? Atau memang harus kombinasi keduanya?
4. Akses Simulator – Apakah kamu sudah familiar atau punya preferensi simulator tertentu? (Isaac Sim, Gazebo, PyBullet, MuJoCo, dll.) Atau ini akan dipelajari dari nol?
5. Ketertarikan Domain – Apakah ada domain aplikasi yang menarik minatmu? Misalnya:
   • Autonomous navigation
   • Manipulation / grasping
   • Human-robot interaction
   • Industrial automation
   • Drone / aerial robotics
6. Research Interest – Apakah ada paper atau topik riset tertentu yang sudah pernah kamu baca atau tertarik untuk dieksplor lebih dalam?

Informasi ini penting karena dengan RTX 5090, kamu punya kemampuan komputasi yang sangat kuat untuk simulasi dan training model. Tapi tanpa arah yang jelas, resource sebesar itu bisa terbuang untuk eksperimen yang tidak terarah.

Setelah kamu jawab, saya akan berikan rekomendasi project utama beserta alternatif yang sesuai dengan format yang diminta.

Terima kasih untuk klarifikasinya, Ricky. Sekarang gambaran profilmu jauh lebih jelas.

Sebelum saya lanjut ke rekomendasi final, ada satu hal penting yang perlu kita bahas dulu karena ini akan sangat mempengaruhi arah project:

Catatan Penting: Tentang "Vibe Coding" di Research Track

Kamu menyebut mengandalkan kemampuan prompting dan toleransi terhadap kegagalan. Ini adalah kekuatan, tapi perlu saya sampaikan dengan jujur:

Research track berbeda dengan development track.

Di research, kamu akan diminta untuk:

• Menjelaskan mengapa sebuah arsitektur dipilih, bukan hanya bahwa itu bekerja
• Menulis paper yang membutuhkan pemahaman mendalam tentang metodologi
• Melakukan ablation study, hyperparameter justification, dan analisis statistik
• Mempertahankan keputusan teknis di depan reviewer dan dosen pembimbing

Vibe coding dengan AI assistant bisa mempercepat implementasi, tapi tidak bisa menggantikan pemahaman fundamental. Reviewer paper akan bertanya hal-hal seperti: "Mengapa pakai PPO dan bukan SAC?", "Apa justifikasi reward function ini?", atau "Bagaimana kamu handle sim-to-real gap?"

Ini bukan untuk menakut-nakuti, tapi untuk memastikan ekspektasi realistis. Dengan timeline 1 tahun dan target 3 paper, kamu perlu:

1. Membangun fondasi teori yang cukup kuat (minimal 2-3 bulan pertama)
2. Menggunakan AI tools untuk akselerasi, bukan substitusi pemahaman

Klarifikasi Tambahan

Sebelum rekomendasi project, saya perlu tahu lebih detail tentang target 3 jurnal:

1. Level jurnal yang ditargetkan – Apakah Sinta-indexed (nasional), Scopus Q3-Q4, atau lebih tinggi? Ini mempengaruhi kompleksitas riset yang dibutuhkan.
2. Apakah 3 paper ini harus dari 1 project besar (dipecah jadi beberapa publikasi), atau 3 project terpisah?
3. Tentang project SpamShield (judol dataset) – Kamu bilang dijadikan "side project", tapi ini sebenarnya sudah punya potensi publikasi yang bagus. Apakah project ini bisa dihitung sebagai salah satu dari 3 target paper, atau memang ingin dipisahkan sepenuhnya?
4. Domain Indonesia – Ketika kamu bilang "domain yang cocok untuk Indonesia", apakah maksudnya:
   • Masalah lokal yang belum banyak diteliti (gap research)?
   • Aplikasi yang relevan dengan industri/kebutuhan Indonesia?
   • Atau keduanya?

Jawab ini dulu, dan saya akan berikan rekomendasi project yang terstruktur dengan pembagian fase untuk 1 tahun ke depan.

Baik, sekarang sudah jauh lebih jelas. Mari saya rangkum dulu pemahamanku untuk memastikan kita aligned:

Ringkasan Situasi

Pertimbangan Sebelum Rekomendasi

Target 3 paper Q2/Scopus dalam 1 tahun itu ambisius tapi bukan tidak mungkin, dengan catatan:

1. SpamShield (judol detection) sudah punya dataset dan progress → ini bisa jadi paper pertama yang paling cepat selesai
2. Paper kedua (skripsi-related) → perlu tahu dulu: apakah ini ekstensi dari SpamShield, atau topik berbeda? Ini penting untuk menghindari overlap yang tidak produktif
3. Paper ketiga (Enrichment - AI & Robotika/IoT) → ini yang akan saya fokuskan rekomendasinya, dan harus standalone dengan novelty tersendiri

Klarifikasi Terakhir untuk Paper Enrichment (AI & Robotika/IoT)

Supaya rekomendasi tepat sasaran untuk konteks Indonesia dan potensi publikasi Q2:

1. Preferensi arah Robotika/IoT:

Mana yang lebih menarik buatmu?

• Robotika simulasi → robot virtual yang belajar bergerak/manipulasi objek (butuh simulator seperti Isaac Sim)
• IoT + Edge AI → sistem embedded dengan sensor yang menjalankan AI di perangkat (lebih dekat ke real-world deployment)
• Kombinasi → simulasi dulu, lalu deploy ke hardware sederhana (misal: ESP32 + kamera)

2. Tentang visi pemerintah Indonesia, beberapa area yang punya gap research dan relevansi tinggi:

• Pertanian presisi (smart agriculture) → selaras dengan ketahanan pangan
• Monitoring lingkungan (polusi, banjir, kebakaran hutan) → disaster mitigation
• Logistik & warehouse automation → mendukung e-commerce dan IKN
• Assistive technology → untuk populasi lansia dan disabilitas
• Smart fisheries → Indonesia sebagai negara maritim

Dari opsi di atas, mana yang paling resonates dengan interest-mu? Atau ada domain lain yang lebih menarik?

3. Tentang paper kedua (skripsi-related selain SpamShield):

Apakah sudah ada bayangan topiknya, atau ini masih terbuka untuk direkomendasikan juga?

Setelah ini saya akan berikan rekomendasi lengkap dengan format yang terstruktur, termasuk bagaimana ketiga paper ini bisa saling melengkapi timeline-nya supaya tidak bentrok.

Excellent. Paper kedua ini sangat solid secara positioning. Robustness/failure analysis memang niche yang sering diterima di IEEE applied venues karena practical contribution-nya jelas.

Sekarang saya sudah punya gambaran lengkap:

Peta 3 Paper Kamu

Paper 1 dan 2 saling melengkapi dan memperkuat skripsi. Keduanya fokus di domain NLP/content moderation.

Paper 3 harus berbeda domain supaya portofolio risetmu tidak terlalu sempit, dan ini sesuai dengan requirement Enrichment Track yang fokus ke AI & Robotika.

Kembali ke Pertanyaan Sebelumnya

Untuk Paper 3 (Enrichment - AI & Robotika/IoT), saya perlu kamu pilih arah:

Preferensi pendekatan:

• Robotika simulasi → robot virtual, reinforcement learning, simulator (Isaac Sim/PyBullet)
• IoT + Edge AI → sensor + embedded AI, real-world deployment
• Kombinasi → simulasi dulu, lalu deploy ke hardware sederhana

Domain aplikasi yang relevan untuk Indonesia:

• Pertanian presisi (smart agriculture)
• Monitoring lingkungan (banjir, polusi, kebakaran)
• Logistik & warehouse automation
• Assistive technology
• Smart fisheries/maritim

Atau kalau kamu punya preferensi domain lain, boleh sebutkan.

Setelah ini saya akan berikan rekomendasi project lengkap dengan format yang sudah ditentukan.

Terima kasih untuk dokumen risetnya, Ricky. Ini sangat membantu untuk mempersempit arah.

Saya sudah baca kedua dokumen dengan seksama. Sebelum memberikan rekomendasi final, izinkan saya memberikan analisis jujur dari perspektif kelayakan riset level Scopus/IEEE Q2 dan kecocokan dengan profil kamu:

Analisis Komparatif: Banjir vs Pertanian

Pendapat Jujur Saya

Domain banjir lebih cocok untuk kamu, dengan alasan:

1. Akses validasi real-world — Kamu tinggal di Jakarta. Bisa observasi langsung kondisi banjir, foto genangan, validasi model dengan ground truth yang kamu lihat sendiri. Ini advantage besar untuk riset.
2. Gap yang masih terbuka — Dokumen kamu sendiri menyebutkan: sistem Pantau Banjir Jakarta tidak mendeteksi passability kendaraan. Ini celah riset yang sangat spesifik dan solvable.
3. Simulation-first friendly — Banjir bisa dimodelkan dengan data historis (curah hujan BMKG, ketinggian air) tanpa harus deploy sensor fisik di awal. Kamu bisa develop dan validasi model di simulator dulu.
4. Alignment dengan visi pemerintah — Disaster mitigation adalah prioritas nasional. Paper di domain ini punya "social relevance" yang kuat untuk reviewer.

Namun, Perlu Saya Ingatkan

Topik "flood prediction with IoT + AI" sudah cukup crowded di level conference. Untuk tembus Q2 journal, kamu butuh angle yang lebih spesifik.

Beberapa angle yang masih punya gap:

Pertanyaan Sebelum Rekomendasi Final

Supaya saya bisa memberikan rekomendasi project yang paling tepat:

1. Seberapa nyaman kamu dengan hardware fisik? Apakah kamu punya pengalaman dengan ESP32, Raspberry Pi, atau sensor apapun? Atau ini benar-benar dari nol?
2. Budget untuk hardware — Dokumen menyebut Rp 1-2 juta untuk MVP. Apakah ini realistis untuk kamu, atau ada constraint budget?
3. Akses ke Prof. Widodo — Apakah beliau punya koneksi ke Jakarta Smart City / BPBD / BMKG yang bisa membantu akses data atau validasi?
4. Preferensi antara:
   • (A) Project yang lebih "safe" dengan novelty sedang tapi completion rate tinggi
   • (B) Project yang lebih ambisius dengan novelty tinggi tapi risiko gagal lebih besar

Setelah kamu jawab, saya akan berikan rekomendasi lengkap dengan format yang sudah ditentukan (judul, tujuan, komponen teknis, fase pengerjaan, risiko, dll).

Ini informasi yang sangat berharga, Ricky.

Analisis Situasi yang Lebih Lengkap

Tentang IoT Kit Samsung Innovation Campus:

Ini starter kit yang bagus untuk pemula. Biasanya berisi ESP32 atau Arduino, beberapa sensor dasar (suhu, kelembaban, ultrasonik, dll), LED, resistor, dan breadboard. Kamu punya modal hardware untuk mulai eksperimen tanpa beli tambahan di awal.

Tentang teman yang sudah berpengalaman:

Ini advantage signifikan. Untuk bagian hardware integration, kamu bisa kolaborasi atau belajar dari temanmu, sementara kamu fokus ke sisi AI dan research methodology.

Tentang Prof. Widodo:

Profil beliau sangat relevan dengan arah project kamu:

• Background Fisika Instrumentasi → paham sensor dan hardware
• Expertise di AI dan Robotika → selaras dengan research track
• Track record produk untuk difabel (Ratanggalih) → menunjukkan beliau value practical application
• Koneksi internasional kuat (Prancis, Jepang) → bisa membantu untuk publikasi dan networking

Yang penting: beliau punya pengalaman membuat produk nyata (kursi roda, robot edukasi), bukan hanya paper teoritis. Ini berarti beliau kemungkinan akan appreciate project yang punya working prototype.

Satu Pertanyaan Terakhir

Sebelum rekomendasi final, saya perlu tahu preferensimu:

Antara dua arah ini, mana yang lebih menarik?

(A) Road Flood Passability Prediction

• Fokus: Memprediksi apakah jalan bisa dilalui kendaraan saat banjir (bukan hanya ketinggian air)
• Novelty: Belum banyak diteliti di Indonesia, praktis untuk navigasi
• Pendekatan: Simulation-first dengan data historis, lalu validasi dengan sensor sederhana
• Cocok untuk: Computer vision + sensor fusion

(B) Edge AI Early Warning System dengan Ultra-Low Latency

• Fokus: Sistem peringatan dini yang bisa jalan di perangkat murah tanpa internet stabil
• Novelty: Fokus ke deployment constraint di daerah dengan infrastruktur terbatas
• Pendekatan: Model compression, TinyML, optimization untuk edge device
• Cocok untuk: Machine learning optimization + embedded systems

Keduanya bisa menggunakan IoT kit yang kamu punya dan memanfaatkan RTX 5090 untuk training. Pilih berdasarkan mana yang lebih resonates dengan interest-mu, karena kamu akan mengerjakan ini selama 1 tahun.

Setelah kamu pilih, saya akan berikan rekomendasi lengkap dengan format yang sudah ditentukan.

Baik, pilihan yang solid. Road Flood Passability Prediction punya kombinasi yang bagus antara novelty, practicality, dan feasibility untuk profilmu.

Sekarang saya berikan rekomendasi lengkap:

Rekomendasi Project Enrichment: AI & Robotika/IoT

📌 Judul Project

"FloodPass: AI-Based Road Passability Prediction System for Urban Flood Navigation in Jakarta"

Judul alternatif untuk paper (IEEE-tone):

"Real-Time Road Passability Classification During Urban Flooding Using Multi-Sensor Fusion and Edge AI: A Case Study in Jakarta, Indonesia"

🎯 Tujuan Project

Tujuan Utama: Mengembangkan sistem yang dapat memprediksi apakah sebuah ruas jalan dapat dilalui kendaraan (passable/not passable) saat kondisi banjir, berdasarkan kombinasi data ketinggian air, karakteristik jalan, dan tipe kendaraan.

Mengapa ini penting:

• Sistem existing (Pantau Banjir Jakarta) hanya menampilkan ketinggian air, tidak memberitahu apakah jalan aman dilalui
• Ketinggian air 30cm bisa passable untuk SUV tapi fatal untuk motor
• Keputusan "nekat lewat atau putar balik" saat ini bergantung pada intuisi pengendara
• Korban jiwa sering terjadi karena kendaraan terjebak di genangan yang terlihat dangkal tapi sebenarnya dalam

Research Gap yang Diisi: Mayoritas penelitian flood monitoring fokus pada prediksi ketinggian air atau early warning. Sangat sedikit yang menerjemahkan data ketinggian menjadi actionable decision untuk pengguna jalan.

🔧 Komponen Teknis

A. Data & Input Sources

B. Tech Stack

AI/ML Layer (memanfaatkan RTX 5090):

• Python + PyTorch untuk model development
• Gradient Boosting atau Random Forest untuk baseline
• Neural network untuk sensor fusion (jika data cukup)
• ONNX untuk model export ke edge device

IoT Layer (memanfaatkan Samsung IoT Kit):

• ESP32 sebagai microcontroller
• Sensor ultrasonik HC-SR04 untuk water level
• DHT22 untuk humidity (indikator hujan)
• Komunikasi via WiFi/MQTT

Edge Deployment:

• Raspberry Pi 4 atau Jetson Nano untuk inference
• TensorFlow Lite atau ONNX Runtime untuk model ringan

Backend & Visualization:

• FastAPI untuk REST API
• PostgreSQL + PostGIS untuk spatial data
• React atau simple dashboard untuk visualisasi
• Leaflet.js untuk peta interaktif

C. Arsitektur Sistem (High-Level)

[Sensor Node] → [MQTT Broker] → [Backend Server] → [AI Model] → [Dashboard/App]
     ↓                                                    ↓
[Water Level]                                    [Passability Score]
[Humidity]                                       [Per Vehicle Type]

📅 Pembagian Fase Pengerjaan (12 Bulan)

Fase 0: Foundation Building (Bulan 1-2)

Target: Bangun fondasi teori dan skill

Milestone: Kamu bisa menjelaskan ke Prof. Widodo mengapa passability berbeda dari water level prediction, dan demo sederhana sensor ultrasonik membaca ketinggian air.

Fase 1: Data Collection & Problem Formulation (Bulan 3-4)

Target: Definisikan problem secara formal dan kumpulkan data awal

Milestone: Dataset awal siap, problem formulation jelas, bisa tulis draft Introduction dan Related Work untuk paper.

Fase 2: Model Development & Simulation (Bulan 5-7)

Target: Develop dan validasi model di environment simulasi

Milestone: Model mencapai performa yang reasonable (target: >80% accuracy pada test set). Draft Methodology untuk paper.

Fase 3: Hardware Integration & Prototype (Bulan 8-9)

Target: Integrasikan model ke hardware fisik

Milestone: Prototype fisik bisa membaca water level dan output passability prediction secara real-time.

Fase 4: Field Validation & Iteration (Bulan 10-11)

Target: Validasi di kondisi nyata

Milestone: Data validasi real-world, bisa tulis Results dan Discussion untuk paper.

Catatan penting: Fase ini bergantung pada musim hujan Jakarta (biasanya Nov-Mar). Timeline harus disesuaikan dengan cuaca.

Fase 5: Paper Writing & Finalization (Bulan 12)

Target: Paper siap submit

Milestone: Paper siap submit ke target venue.

⚠️ Risiko & Kegagalan yang Mungkin Terjadi

Risiko Tinggi

Risiko Sedang

Risiko Rendah (tapi perlu diperhatikan)

📈 Dampak terhadap Peningkatan Skill

Technical Skills

Research Skills

Soft Skills

📓 Sistem Catatan / Logbook yang Disarankan

Format Logbook Harian

# [Tanggal] - [Judul Aktivitas]

## Apa yang dikerjakan hari ini
- [Bullet points aktivitas]

## Hasil / Output
- [Concrete output: file, code, document, dll]

## Masalah yang ditemui
- [Problems encountered]

## Solusi / Next step
- [How you solved it or plan to solve it]

## Waktu yang dihabiskan
- [X jam]

## Catatan untuk diri sendiri
- [Personal notes, insights, ideas]

Tools yang Direkomendasikan

Weekly Review Template

# Week [X] Review

## Accomplishments
- [What was completed]

## Blockers
- [What's preventing progress]

## Learnings
- [New knowledge acquired]

## Next Week Plan
- [Priorities for next week]

## Health Check
- On track / Behind / Ahead
- Confidence level: [1-5]

Monthly Checkpoint dengan Prof. Widodo

Setiap bulan, siapkan:

1. Progress summary (1 halaman)
2. Demo jika ada prototype
3. Blockers yang butuh bantuan
4. Plan untuk bulan depan

🎯 Target Publikasi

Primary Target:

• IEEE Access (Q1, tapi acceptance rate tinggi)
• IEEE Internet of Things Journal (Q1)
• Sensors (MDPI, Q2)

Backup Target:

• International Conference on IoT (IEEE)
• International Conference on Intelligent Transportation Systems
• Jurnal nasional Scopus-indexed sebagai fallback

Timeline Publikasi:

• Bulan 10-11: Submit paper
• Bulan 12+: Revision cycle (jika diperlukan)

🔄 Alternatif Project (Backup)

Jika project utama menghadapi kendala besar, berikut alternatif yang masih dalam domain sama:

Alternatif 1: Flood Sensor Placement Optimization using Reinforcement Learning

• Fokus: Dimana sebaiknya sensor ditempatkan untuk coverage optimal dengan budget terbatas
• Lebih simulation-heavy, kurang butuh validasi real-world

Alternatif 2: Crowdsourced Flood Reporting Validation using AI

• Fokus: Memvalidasi laporan banjir dari masyarakat menggunakan AI (fake report detection)
• Lebih NLP-focused, bisa leverage skill dari SpamShield

Alternatif 3: Flood Impact Prediction on Traffic Flow

• Fokus: Memprediksi dampak banjir terhadap kemacetan
• Bisa pakai data Google Maps API + historical flood data

✅ Immediate Next Steps (Minggu Ini)

1. Diskusikan dengan Prof. Widodo — Presentasikan ide ini, minta feedback dan approval
2. Inventory IoT Kit — Buka Samsung IoT Kit, dokumentasikan isinya, test apakah semua komponen berfungsi
3. Setup research environment — Install Python, PyTorch, create GitHub repo, setup Notion untuk logbook
4. Mulai literature review — Cari 10 paper tentang flood passability, flood prediction, dan sensor fusion

Apakah ada bagian yang perlu saya jelaskan lebih detail, Ricky? Atau ada penyesuaian yang perlu dilakukan berdasarkan constraint yang belum saya ketahui?

Terima kasih untuk prompt yang sangat terstruktur ini, Ricky. Ini menunjukkan kamu sudah berpikir kritis tentang feasibility — skill penting untuk researcher.

Mari saya lakukan revisi menyeluruh dengan pendekatan yang lebih defensible:

FloodPass v2: Revisi Realistis untuk Research Track

1. Reality Check & Asumsi Rapuh

5 Asumsi Paling Rapuh dari Desain Sebelumnya

Mengapa Asumsi Ini Berbahaya untuk Mahasiswa

1. Ketergantungan pada external factors — Musim hujan, izin pemerintah, ketersediaan data bukan dalam kontrol kamu
2. Scope creep — Setiap asumsi yang tidak terpenuhi akan memaksa pivot di tengah jalan
3. Tidak reproducible — Jika data/sensor hanya tersedia di kondisi tertentu, reviewer tidak bisa memverifikasi
4. Ethical liability — Klaim "passable" bisa diinterpretasi sebagai rekomendasi, padahal model pasti punya error

2. Redefinisi Output: Risk-Based Approach

Dari Binary Classification ke Risk Score

Sebelumnya (Berbahaya):

Output: "Jalan Kemang Raya: PASSABLE untuk mobil"

Sesudah (Lebih Aman & Ilmiah):

Output: "Jalan Kemang Raya: Risk Score 7.2/10 untuk mobil sedan
        - Confidence: 68%
        - Faktor risiko utama: Ketinggian air estimasi 35cm, 
          drainase buruk, riwayat kendaraan terjebak
        - Rekomendasi: Pertimbangkan rute alternatif"

Mengapa Pendekatan Risk Score Lebih Tepat

Secara Ilmiah:

• Passability bukan binary — ada spektrum dari "aman" hingga "pasti terjebak"
• Uncertainty bisa dikuantifikasi dan dikomunikasikan
• Lebih jujur terhadap limitasi model

Secara Etis:

• Tidak membuat keputusan untuk user, hanya memberikan informasi
• User tetap punya agency untuk memutuskan
• Jika terjadi insiden, sistem tidak "menyuruh" user lewat

Secara Praktis:

• Lebih useful — user bisa bandingkan risk score antar rute
• Bisa di-threshold sesuai risk tolerance masing-masing user
• Lebih mudah di-calibrate dan di-improve

Komponen Risk Score

Risk Score (0-10) = f(water_level_estimate, 
                      road_characteristics,
                      vehicle_vulnerability,
                      historical_incident_rate,
                      uncertainty_penalty)

3. Desain MVP Revisi (Tanpa Sensor, Tanpa Real-Time)

Scope MVP yang Realistis

Apa yang MVP ini BISA lakukan:

• Memberikan risk score untuk ruas jalan tertentu di Jakarta berdasarkan skenario curah hujan
• Membandingkan risiko antar tipe kendaraan
• Menunjukkan faktor-faktor yang berkontribusi ke risk score
• Demonstrasi via dashboard statis dengan historical scenarios

Apa yang MVP ini TIDAK lakukan:

• Prediksi real-time
• Integrasi dengan sensor live
• Rekomendasi routing otomatis
• Klaim definitif "boleh lewat" atau "tidak boleh lewat"

Data yang Realistis Tersedia di Jakarta

Data yang TIDAK Bisa Diandalkan

Arsitektur MVP Sederhana

┌─────────────────────────────────────────────────────────────┐
│                     DATA LAYER (Offline)                     │
├─────────────────────────────────────────────────────────────┤
│  Curah Hujan    Road Network    Elevation    Historical     │
│  (BMKG CSV)     (OSM GeoJSON)   (SRTM DEM)   Flood Points   │
└──────────┬──────────────┬────────────┬────────────┬─────────┘
           │              │            │            │
           ▼              ▼            ▼            ▼
┌─────────────────────────────────────────────────────────────┐
│                   PROCESSING LAYER                           │
├─────────────────────────────────────────────────────────────┤
│  Water Level     Road Risk      Vehicle        Incident     │
│  Estimation      Features       Profiles       Extraction   │
│  Model           Engineering                   (dari berita)│
└──────────┬──────────────┬────────────┬────────────┬─────────┘
           │              │            │            │
           ▼              ▼            ▼            ▼
┌─────────────────────────────────────────────────────────────┐
│                    MODEL LAYER                               │
├─────────────────────────────────────────────────────────────┤
│           Risk Score Model (Rule-based + ML hybrid)          │
│           + Confidence Estimation                            │
└─────────────────────────┬───────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────────┐
│                    OUTPUT LAYER                              │
├─────────────────────────────────────────────────────────────┤
│  Interactive Dashboard    Risk Map    Scenario Comparison    │
│  (Streamlit / React)      (Leaflet)   (What-if analysis)    │
└─────────────────────────────────────────────────────────────┘

Model Baseline: Rule-Based vs ML

Rekomendasi: Hybrid Approach

Stage 1 — Rule-Based Baseline (Minggu 1-4):

def calculate_risk_score_v1(water_level_cm, ground_clearance_cm, 
                            road_drainage_quality, historical_incidents):
    
    # Core risk: rasio ketinggian air vs ground clearance
    clearance_ratio = water_level_cm / ground_clearance_cm
    
    if clearance_ratio < 0.3:
        base_risk = 2
    elif clearance_ratio < 0.5:
        base_risk = 4
    elif clearance_ratio < 0.7:
        base_risk = 6
    elif clearance_ratio < 0.9:
        base_risk = 8
    else:
        base_risk = 10
    
    # Modifiers
    drainage_modifier = {"good": -1, "moderate": 0, "poor": +1}
    incident_modifier = min(historical_incidents * 0.5, 2)
    
    risk_score = base_risk + drainage_modifier[road_drainage_quality] + incident_modifier
    
    return max(0, min(10, risk_score))  # Clamp to 0-10
```

**Stage 2 — ML Enhancement (Minggu 5-8):**
- Train model untuk memprediksi water_level dari curah hujan + elevasi + karakteristik area
- Gunakan gradient boosting (XGBoost/LightGBM) karena interpretable
- Compare dengan rule-based baseline

**Mengapa Hybrid:**
- Rule-based memberikan explainability dan baseline yang jelas
- ML bisa capture patterns yang tidak obvious dari data
- Jika ML tidak improve signifikan, rule-based tetap valid sebagai kontribusi

### Output yang Bisa Didemokan

1. **Interactive Dashboard:**
   - User pilih lokasi (dropdown atau klik peta)
   - User pilih skenario curah hujan (ringan/sedang/lebat/ekstrem)
   - User pilih tipe kendaraan
   - Output: Risk score + breakdown faktor + confidence

2. **Scenario Comparison:**
   - Bandingkan risk score untuk berbagai rute dari A ke B
   - Visualisasi "jika hujan lebat, rute mana yang paling aman"

3. **Historical Replay:**
   - Pilih tanggal banjir historis (misal: 1 Jan 2020)
   - Lihat risk score yang seharusnya muncul saat itu
   - Validasi dengan berita kendaraan terjebak di tanggal tersebut

---

## 4. Labeling & Ground Truth Strategy

### Masalah Fundamental: Tidak Ada Ground Truth Langsung

Idealnya, ground truth adalah: "Pada tanggal X, jam Y, di jalan Z dengan ketinggian air W cm, kendaraan tipe V berhasil/gagal melewati."

**Kenyataannya:** Data ini tidak ada dan tidak mungkin dikumpulkan secara sistematis oleh 1 mahasiswa.

### Solusi: Proxy Labels & Weak Supervision

**Strategi 1: Incident-Based Negative Labels**

Dari berita dan media sosial, ekstrak kejadian kendaraan terjebak:
```
"Motor terjebak di Jl. Kemang Raya saat banjir 50cm" 
→ Label: Jl. Kemang Raya, water_level ~50cm, vehicle=motor, outcome=FAILED
```

**Kelebihan:** Data nyata, bisa diverifikasi
**Kekurangan:** Hanya negative cases (yang berhasil lewat tidak diberitakan), selection bias

**Strategi 2: Physics-Based Synthetic Labels**

Gunakan pengetahuan fisika sederhana:
```
IF water_level > ground_clearance * 0.8:
    label = HIGH_RISK (synthetic)
IF water_level > intake_height:
    label = ENGINE_DAMAGE_RISK (synthetic)
```

**Kelebihan:** Bisa generate banyak data, based on engineering principles
**Kekurangan:** Simplified, tidak capture semua faktor real-world

**Strategi 3: Expert Elicitation (Opsional)**

Wawancara 5-10 orang yang sering berkendara di Jakarta saat banjir:
```
"Pada kondisi seperti ini [tampilkan foto/skenario], 
apakah Anda akan mencoba melewati dengan [tipe kendaraan]?"
```

**Kelebihan:** Human judgment, bisa capture tacit knowledge
**Kekurangan:** Subjektif, small sample size

### Combined Labeling Strategy yang Direkomendasikan
```
┌─────────────────────────────────────────────────────────────┐
│                    LABELING STRATEGY                         │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  1. NEGATIVE LABELS (High Confidence)                        │
│     Source: News extraction of stuck vehicles                │
│     Label: HIGH_RISK / FAILED                                │
│     Quantity: Target 50-100 incidents                        │
│                                                              │
│  2. SYNTHETIC LABELS (Medium Confidence)                     │
│     Source: Physics-based rules                              │
│     Label: Risk score based on clearance ratio               │
│     Quantity: Generate untuk semua road segments             │
│                                                              │
│  3. BOUNDARY CASES (Low Confidence, for analysis)            │
│     Source: Expert elicitation / survey                      │
│     Label: Subjective risk assessment                        │
│     Quantity: 50-100 scenarios                               │
│                                                              │
│  Confidence weighting in training:                           │
│  Negative labels (1.0) > Synthetic (0.6) > Expert (0.4)     │
│                                                              │
└─────────────────────────────────────────────────────────────┘
```

### Risiko Bias & Noise yang Harus Diakui dalam Paper

| Bias/Noise | Deskripsi | Mitigasi | Acknowledgment dalam Paper |
|------------|-----------|----------|---------------------------|
| **Selection bias** | Hanya kendaraan terjebak yang diberitakan, bukan yang berhasil | Gunakan synthetic labels untuk balance | "Our negative labels are derived from reported incidents, which may not represent all failure cases" |
| **Reporting bias** | Daerah tertentu lebih sering diliput media | Normalize by media coverage per area | "Incident frequency may reflect media coverage patterns rather than actual risk distribution" |
| **Temporal shift** | Kondisi drainase berubah seiring waktu | Fokus pada data 3-5 tahun terakhir | "Road conditions may have changed; our model reflects historical patterns" |
| **Vehicle variation** | Kondisi kendaraan (ban, modifikasi) tidak diketahui | Gunakan spesifikasi standar | "We assume vehicles are in standard condition as per manufacturer specifications" |

---

## 5. Evaluation Plan yang Masuk Akal

### Baseline Comparisons

| Baseline | Deskripsi | Mengapa Penting |
|----------|-----------|-----------------|
| **Random baseline** | Risk score random 0-10 | Memastikan model better than chance |
| **Water-level-only baseline** | Risk = f(water_level) saja | Memastikan fitur tambahan berguna |
| **Rule-based baseline** | Versi v1 tanpa ML | Memastikan ML memberikan improvement |
| **Single-vehicle baseline** | Model tanpa vehicle differentiation | Memastikan vehicle-specific modeling berguna |

### Jenis Evaluasi yang Relevan

**1. Discriminative Performance (apakah model bisa membedakan high vs low risk)**
- Metrics: AUC-ROC, Precision-Recall pada high-risk threshold
- Mengapa: Lebih penting bisa identify high-risk cases daripada exact score

**2. Calibration (apakah confidence score meaningful)**
- Metrics: Expected Calibration Error (ECE), Reliability diagram
- Mengapa: Jika model bilang "confidence 80%", apakah benar 80% akurat?

**3. Ablation Study (kontribusi tiap komponen)**
- Hapus satu fitur/komponen, ukur performance drop
- Mengapa: Menunjukkan setiap bagian sistem punya kontribusi

**4. Robustness Analysis**
- Test dengan variasi input (noise pada curah hujan, missing data)
- Mengapa: Real-world data tidak sempurna

**5. Error Analysis (kualitatif)**
- Analisis manual 20-30 cases dengan error terbesar
- Identifikasi pattern: kapan model salah?
- Mengapa: Insight untuk improvement dan honest limitation

### Kapan Model Dianggap "Cukup Baik"

**Bukan tentang angka absolut, tapi tentang:**

1. **Better than baselines** — Jika ML model tidak beat rule-based, fokus paper ke rule-based + analysis

2. **Reasonable calibration** — Confidence score harus meaningful, tidak harus sempurna

3. **Explainable errors** — Kita bisa jelaskan mengapa model salah di cases tertentu

4. **Useful for decision support** — Dalam user study sederhana, apakah risk score membantu orang membuat keputusan lebih baik?

**Threshold realistis untuk riset mahasiswa:**
- AUC-ROC > 0.7 untuk high-risk detection
- ECE < 0.15 untuk calibration
- Improvement > 10% vs simplest baseline

**Jika tidak tercapai:** Tetap valid sebagai riset, tapi framing berubah ke "analysis of challenges in flood passability prediction" — mirip dengan paper kedua kamu tentang Unicode obfuscation.

---

## 6. Roadmap Revisi: 8-12 Minggu

### Overview Timeline
```
Week 1-2:  Setup & Data Collection
Week 3-4:  Data Processing & Feature Engineering  
Week 5-6:  Baseline Model & Rule-Based System
Week 7-8:  ML Model Development
Week 9-10: Evaluation & Analysis
Week 11-12: Dashboard & Paper Draft

Detail Per Minggu

Minggu 1: Project Setup & Initial Data Collection

Deliverable Minggu 1:

• GitHub repo terstruktur
• 3 raw datasets downloaded
• Logbook entry #1

Minggu 2: News Scraping & Incident Extraction

Deliverable Minggu 2:

• Incident dataset v1 (50+ labeled incidents)
• Flood points dataset
• Data dictionary

Minggu 3: Data Processing & Integration

Deliverable Minggu 3:

• Integrated dataset v1
• EDA notebook dengan visualisasi
• Preliminary insights document

Minggu 4: Feature Engineering & Vehicle Profiles

Deliverable Minggu 4:

• Complete modeling dataset
• Feature documentation
• Vehicle profiles database

Minggu 5: Rule-Based Baseline System

Deliverable Minggu 5:

• Working rule-based system
• Baseline performance metrics
• Methodology document

Minggu 6: Water Level Estimation Model

Deliverable Minggu 6:

• Water level estimation module
• Validation results
• Integrated system v1

Minggu 7: ML Model Development

Deliverable Minggu 7:

• Trained ML model
• Tuning notebook
• Comparison analysis

Minggu 8: Confidence Estimation & Calibration

Deliverable Minggu 8:

• Calibrated model
• Calibration analysis
• Final model selection documented

Minggu 9: Comprehensive Evaluation

Deliverable Minggu 9:

• Complete evaluation results
• Ablation study
• Error analysis document

Minggu 10: Dashboard Development

Deliverable Minggu 10:

• Working Streamlit dashboard
• Demo video (2-3 menit)

Minggu 11: Paper Writing - Draft

Deliverable Minggu 11:

• Complete paper draft v1
• All figures and tables

Minggu 12: Revision & Finalization

Deliverable Minggu 12:

• Final paper ready for submission
• Clean GitHub repo
• Complete documentation

Checkpoint Summary

7. Final Novelty Statement

Versi untuk Paper (Abstract-ready)

"This study presents FloodPass, a risk assessment framework for evaluating road passability during urban flooding in Jakarta, Indonesia. Unlike existing flood monitoring systems that report only water levels, FloodPass translates hydrological data into vehicle-specific risk scores by integrating rainfall patterns, road characteristics, and vehicle vulnerability profiles. We construct a novel dataset combining historical flood incidents extracted from news media with physics-based synthetic labels, addressing the absence of ground-truth passability data. Our evaluation demonstrates that the proposed approach outperforms water-level-only baselines in identifying high-risk road segments, while calibrated confidence scores enable users to make informed routing decisions. This work contributes a practical methodology for flood risk communication applicable to cities with limited sensor infrastructure."

Breakdown Klaim Novelty

Apa yang TIDAK Diklaim

• ❌ Tidak mengklaim sebagai "definitive passability predictor"
• ❌ Tidak mengklaim real-time capability
• ❌ Tidak mengklaim model terbaik / state-of-the-art
• ❌ Tidak mengklaim menggantikan sistem pemerintah
• ❌ Tidak mengklaim zero risk jika score rendah

Penutup: Apa yang Berubah dari v1 ke v2

Apakah ada bagian yang perlu saya elaborasi lebih lanjut, Ricky? Atau ada constraint tambahan yang belum saya pertimbangkan?

FloodPass v2.1 – Revised & Defensible Design

1. Revised Problem Framing

Masalah yang Diselesaikan (Versi Jujur)

Framing Lama (Terlalu Ambisius):

"Memprediksi apakah jalan bisa dilalui kendaraan saat banjir berdasarkan estimasi ketinggian air real-time"

Framing Baru (Realistis & Defensible):

"Mengembangkan framework untuk menilai flood exposure risk pada ruas jalan di Jakarta dengan mempertimbangkan karakteristik kendaraan, menggunakan data publik yang tersedia tanpa bergantung pada sensor real-time"

Perubahan Kunci dalam Framing

Research Questions (Revisi)

RQ1: Bagaimana flood exposure pada ruas jalan dapat dimodelkan menggunakan data publik tanpa sensor ketinggian air langsung?

RQ2: Sejauh mana karakteristik kendaraan (ground clearance, tipe) mempengaruhi flood risk assessment dibandingkan pendekatan vehicle-agnostic?

RQ3: Bagaimana uncertainty dalam flood risk estimation dapat dikuantifikasi dan dikomunikasikan untuk mendukung pengambilan keputusan?

Scope Statement (Eksplisit)

FloodPass v2.1 ADALAH:

• Decision support system berbasis data historis
• Risk intelligence layer, bukan routing recommendation
• Case study pada area terbatas di Jakarta
• Proof-of-concept methodology

FloodPass v2.1 BUKAN:

• Sistem prediksi real-time
• Pengganti early warning system pemerintah
• Rekomendasi "boleh lewat" atau "tidak boleh lewat"
• Solusi skala kota yang siap deploy

Disclaimer Etis (Wajib Ada di Paper & Dashboard)

DISCLAIMER: FloodPass adalah sistem pendukung keputusan untuk tujuan 
penelitian. Output berupa risk score BUKAN rekomendasi untuk melewati 
atau menghindari ruas jalan tertentu. Pengguna bertanggung jawab penuh 
atas keputusan perjalanan mereka. Selalu ikuti arahan resmi dari 
BPBD, kepolisian, dan otoritas terkait saat kondisi banjir.

2. Revised Data Strategy

Prinsip Data Strategy

1. Reproducibility first — Semua core data harus bisa diakses reviewer tanpa izin khusus
2. No single point of failure — Project tidak boleh gagal karena satu sumber data tidak tersedia
3. Honest about limitations — Acknowledge data gaps dalam paper, jangan hide

Data Classification: Core vs Optional

🟢 CORE DATA (Wajib, Pasti Tersedia, Reproducible)

Mengapa ini "Core":

• Petabencana.id adalah platform crowdsourced dengan API publik terdokumentasi
• OSM adalah standar de facto untuk geodata research
• SRTM elevation tersedia global, gratis
• Data Terbuka BMKG adalah inisiatif resmi, akses tanpa izin
• Vehicle specs adalah data publik dari manufacturer

🟡 OPTIONAL ENRICHMENT (Jika Waktu & Akses Memungkinkan)

Perlakuan Optional Data:

• Tidak masuk critical path
• Jika berhasil didapat → enrichment & bonus analysis
• Jika gagal → project tetap bisa selesai
• Dokumentasikan sebagai "future work" jika tidak sempat

🔴 EXCLUDED (Jangan Diandalkan)

Data Collection Workflow (Core Only)

┌─────────────────────────────────────────────────────────────┐
│                 CORE DATA PIPELINE                           │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  STEP 1: Geographic Scope Definition                         │
│  ─────────────────────────────────────                      │
│  • Define study area: 1-2 koridor (polygon)                 │
│  • Tool: QGIS / Python shapely                              │
│  • Output: study_area.geojson                               │
│                                                              │
│  STEP 2: Road Network Extraction                            │
│  ─────────────────────────────────                          │
│  • Query OSM via Overpass API                               │
│  • Filter: highway=primary/secondary/tertiary               │
│  • Segment into ~200-500m chunks                            │
│  • Output: road_segments.geojson (~50-200 segments)         │
│                                                              │
│  STEP 3: Elevation Extraction                               │
│  ───────────────────────────                                │
│  • Download SRTM tile for Jakarta                           │
│  • Extract elevation per road segment (mean, min, std)      │
│  • Output: road_elevation.csv                               │
│                                                              │
│  STEP 4: Historical Flood Reports                           │
│  ─────────────────────────────────                          │
│  • Query Petabencana API (2020-2025)                        │
│  • Filter by study area polygon                             │
│  • Output: flood_reports.csv (~100-500 reports)             │
│                                                              │
│  STEP 5: Rainfall Data                                      │
│  ─────────────────────                                      │
│  • Download BMKG data terbuka for nearest station           │
│  • Daily rainfall 2020-2025                                 │
│  • Output: rainfall_daily.csv                               │
│                                                              │
│  STEP 6: Integration                                        │
│  ────────────────────                                       │
│  • Spatial join: flood reports → road segments              │
│  • Temporal join: rainfall → flood events                   │
│  • Output: integrated_dataset.csv                           │
│                                                              │
└─────────────────────────────────────────────────────────────┘

Data Volume Expectations (Realistic)

3. Revised Risk Modeling & Uncertainty

Konsep Baru: Flood Exposure Proxy (Bukan Water Level Estimation)

Mengapa Perubahan Ini Penting:

Desain v2 mengasumsikan kita bisa mengestimasi ketinggian air dari rainfall + elevasi. Ini tidak valid secara hidrologi karena:

• Ketinggian air tergantung pada kapasitas drainase (tidak diketahui)
• Aliran air tergantung pada topografi mikro (SRTM terlalu kasar)
• Durasi hujan sama pentingnya dengan intensitas

Pendekatan Baru: Flood Exposure State

Alih-alih memprediksi "berapa cm air", kita memodelkan "seberapa terpapar lokasi ini terhadap banjir" sebagai proxy.

Flood Exposure State ∈ {LOW, MODERATE, HIGH, SEVERE}

Berdasarkan:
- Riwayat flood reports di/dekat lokasi
- Elevasi relatif terhadap sekitarnya  
- Temporal proximity ke rainfall event
- Karakteristik jalan (proxy untuk drainase)

Risk Score Framework (Revisi)

Komponen Risk Score

Risk Score = f(Flood Exposure, Vehicle Vulnerability, Uncertainty)

Dimana:
- Flood Exposure: proxy berbasis data historis & karakteristik lokasi
- Vehicle Vulnerability: berbasis ground clearance & tipe kendaraan
- Uncertainty: quantified confidence dalam estimasi

Menghilangkan Arbitrary Weights

Masalah v2: Bobot 40/25/20/10/5 tidak memiliki justifikasi

Solusi v2.1: Tiga opsi, pilih salah satu berdasarkan hasil eksperimen

Opsi A: Data-Driven Weights (Preferred)

# Gunakan tree-based model yang secara implisit mempelajari feature importance
from sklearn.ensemble import GradientBoostingClassifier

model = GradientBoostingClassifier()
model.fit(X_features, y_flood_exposure)

# Feature importance dari model = learned weights
weights = model.feature_importances_

Opsi B: Sensitivity Analysis

# Uji stabilitas output terhadap variasi weight
weight_combinations = generate_weight_grid()  # e.g., 100 kombinasi

results = []
for weights in weight_combinations:
    risk_scores = calculate_risk(features, weights)
    correlation_with_incidents = evaluate(risk_scores, incidents)
    results.append((weights, correlation_with_incidents))

# Report: "Risk score stable across weight variations (Spearman ρ > 0.85)"
# Atau: "Risk score sensitive to X weight, suggesting importance of X"
```

**Opsi C: Literature-Justified MCDA**
```
Jika menggunakan fixed weights, harus dijustifikasi dengan:
1. Referensi ke paper sejenis yang menggunakan bobot serupa
2. Expert elicitation (wawancara dengan pakar, dokumentasikan proses)
3. AHP (Analytic Hierarchy Process) dengan pairwise comparison

Rekomendasi untuk MVP: Gunakan Opsi A (data-driven) sebagai primary, Opsi B (sensitivity) sebagai validation.

Uncertainty Quantification (Revisi Mendalam)

Mengapa Uncertainty Penting

• FloodPass memberi informasi untuk keputusan yang bisa berdampak keselamatan
• "Risk Score 7" tanpa confidence bisa misleading
• Uncertainty yang jujur adalah kontribusi ilmiah, bukan kelemahan

Metode Uncertainty yang Akan Diimplementasi

1. Epistemic Uncertainty (Model Uncertainty)

# Bootstrap aggregating untuk estimasi variance
from sklearn.utils import resample

n_bootstrap = 100
predictions = []

for i in range(n_bootstrap):
    # Resample training data
    X_boot, y_boot = resample(X_train, y_train)
    
    # Train model on bootstrap sample
    model_boot = GradientBoostingClassifier()
    model_boot.fit(X_boot, y_boot)
    
    # Predict
    pred = model_boot.predict_proba(X_test)
    predictions.append(pred)

# Uncertainty = standard deviation across bootstrap predictions
uncertainty = np.std(predictions, axis=0)

2. Aleatoric Uncertainty (Data Uncertainty)

# Berbasis feature reliability
def calculate_data_uncertainty(segment):
    uncertainty_components = []
    
    # Flood report recency
    days_since_last_report = segment['days_since_flood_report']
    if days_since_last_report > 365:
        uncertainty_components.append(0.3)  # High uncertainty
    elif days_since_last_report > 180:
        uncertainty_components.append(0.15)
    else:
        uncertainty_components.append(0.05)
    
    # Number of historical reports (more data = less uncertainty)
    n_reports = segment['n_flood_reports']
    uncertainty_components.append(max(0, 0.2 - n_reports * 0.02))
    
    # Elevation data quality (SRTM has ~16m vertical error)
    uncertainty_components.append(0.1)  # Fixed component
    
    return sum(uncertainty_components)

3. Combined Confidence Score

def calculate_confidence(model_uncertainty, data_uncertainty):
    """
    Confidence = 1 - combined_uncertainty
    
    Combined using quadrature (independent uncertainties)
    """
    combined = np.sqrt(model_uncertainty**2 + data_uncertainty**2)
    confidence = max(0, min(1, 1 - combined))
    
    return confidence

4. Calibration (Post-hoc)

from sklearn.calibration import CalibratedClassifierCV

# Isotonic regression calibration
calibrated_model = CalibratedClassifierCV(
    base_estimator=model, 
    method='isotonic',
    cv=5
)
calibrated_model.fit(X_train, y_train)

# Evaluate calibration
from sklearn.calibration import calibration_curve
prob_true, prob_pred = calibration_curve(y_test, calibrated_probs, n_bins=10)
```

#### Output Uncertainty yang Akan Ditampilkan
```
Road Segment: Jl. Kemang Raya (Segment 12)
────────────────────────────────────────
Flood Exposure State: HIGH
Risk Score: 7.2 / 10

Vehicle-Specific Assessment:
┌──────────────┬─────────────┬────────────────┐
│ Vehicle Type │ Risk Score  │ Confidence     │
├──────────────┼─────────────┼────────────────┤
│ Motor        │ 8.5 (HIGH)  │ 72% ± 8%       │
│ Sedan        │ 7.2 (HIGH)  │ 68% ± 10%      │
│ SUV          │ 5.1 (MOD)   │ 61% ± 12%      │
└──────────────┴─────────────┴────────────────┘

Uncertainty Factors:
- Last flood report: 45 days ago (low uncertainty)
- Historical reports in area: 12 (moderate confidence)
- Elevation data resolution: 30m (inherent limitation)

⚠️ Confidence below 70% indicates high uncertainty. 
   Exercise additional caution.
```

---

## 4. Revised MVP Scope

### Geographic Scope: Dari Jakarta ke Koridor Spesifik

**Sebelumnya (v2):** Seluruh Jakarta (664 km²)

**Sekarang (v2.1):** 1-2 koridor rawan banjir (~5-10 km total panjang jalan)

#### Kandidat Koridor (Pilih 1-2)

| Koridor | Alasan Dipilih | Panjang Est. | Flood Reports (Est.) |
|---------|----------------|--------------|----------------------|
| **Kemang - Bangka** | Langganan banjir, banyak berita, dekat pusat kota | ~3 km | Tinggi |
| **Kelapa Gading Boulevard** | Area komersial, sering viral saat banjir | ~4 km | Tinggi |
| **Jl. Tendean - Mampang** | Koridor utama, data kemungkinan lengkap | ~3 km | Sedang-Tinggi |
| **Cawang - Kalimalang** | Underpass rawan, kasus kendaraan terjebak banyak | ~5 km | Tinggi |

**Rekomendasi:** Pilih **Kemang - Bangka** sebagai primary study area karena:
- Proximity ke area yang kamu kenal (Jakarta Selatan)
- Banyak liputan media (memudahkan validasi)
- Variasi tipe jalan (jalan besar + gang)

#### Scope dalam Angka

| Metric | Target v2.1 |
|--------|-------------|
| Total road segments | 30-50 segments |
| Flood reports (Petabencana) | 50-100 reports dalam study area |
| Time period | 2020-2025 (5 tahun) |
| Vehicle types | 5 (motor, sedan, SUV, pickup, bus/truk) |

### Functional Scope: Apa yang MVP Bisa Lakukan

**BISA:**
1. Menampilkan risk score per road segment untuk skenario tertentu
2. Membandingkan risk antar vehicle types
3. Menunjukkan historical flood patterns di koridor
4. Memberikan confidence/uncertainty untuk setiap estimasi
5. Replay skenario banjir historis ("Bagaimana risk score pada tanggal X?")

**TIDAK BISA:**
1. Real-time monitoring
2. Routing / navigation
3. Push notification / alert
4. Prediksi banjir besok

### Deliverable MVP yang Konkret
```
FloodPass MVP v2.1 Deliverables:
────────────────────────────────

1. Dataset (Reproducible)
   ├── road_segments.geojson (30-50 segments)
   ├── flood_reports.csv (50-100 reports)
   ├── integrated_features.csv
   └── vehicle_profiles.csv

2. Model Artifacts
   ├── flood_exposure_model.pkl
   ├── risk_score_model.pkl
   ├── calibration_model.pkl
   └── model_evaluation_report.pdf

3. Analysis Notebooks
   ├── 01_data_exploration.ipynb
   ├── 02_feature_engineering.ipynb
   ├── 03_model_training.ipynb
   ├── 04_evaluation.ipynb
   └── 05_uncertainty_analysis.ipynb

4. Dashboard (Streamlit)
   └── Interactive demo dengan:
       - Map visualization
       - Scenario selector
       - Vehicle comparison
       - Historical replay

5. Documentation
   ├── README.md
   ├── data_dictionary.md
   ├── methodology.md
   └── limitations.md

6. Paper Draft
   └── IEEE-format paper ready for review

5. Revised Evaluation Plan

Evaluation Philosophy

Bukan tentang angka tinggi. Tentang:

1. Apakah model lebih baik dari baseline yang reasonable?
2. Apakah setiap komponen berkontribusi?
3. Apakah model jujur tentang ketidakpastiannya?
4. Apakah kita memahami kapan model gagal?

Baseline Definitions

Evaluation Metrics

A. Discriminative Performance

# Primary: Apakah model bisa membedakan high-risk vs low-risk?
from sklearn.metrics import roc_auc_score, average_precision_score

# Binary: HIGH_RISK vs NOT
y_binary = (flood_exposure >= 'HIGH').astype(int)
auc_roc = roc_auc_score(y_binary, risk_scores)
auc_pr = average_precision_score(y_binary, risk_scores)

# Target: AUC-ROC > 0.70, AUC-PR > 0.50 (given imbalanced data)

B. Calibration Quality

from sklearn.calibration import calibration_curve
import matplotlib.pyplot as plt

# Expected Calibration Error (ECE)
def expected_calibration_error(y_true, y_prob, n_bins=10):
    bin_boundaries = np.linspace(0, 1, n_bins + 1)
    ece = 0
    for i in range(n_bins):
        in_bin = (y_prob >= bin_boundaries[i]) & (y_prob < bin_boundaries[i+1])
        if in_bin.sum() > 0:
            avg_confidence = y_prob[in_bin].mean()
            avg_accuracy = y_true[in_bin].mean()
            ece += in_bin.sum() * abs(avg_confidence - avg_accuracy)
    return ece / len(y_true)

# Target: ECE < 0.15
ece = expected_calibration_error(y_test, calibrated_probs)

C. Ablation Study

# Systematic removal of components
ablation_results = {}

feature_groups = {
    'elevation': ['elev_mean', 'elev_min', 'elev_relative'],
    'historical': ['n_flood_reports', 'days_since_last', 'flood_frequency'],
    'road_char': ['road_type', 'road_width', 'has_drainage_proxy'],
    'rainfall': ['rainfall_sum_7d', 'rainfall_max_1d'],
    'vehicle': ['ground_clearance', 'vehicle_type']
}

for group_name, features in feature_groups.items():
    # Train without this group
    X_ablated = X_train.drop(columns=features)
    model_ablated = train_model(X_ablated, y_train)
    score_ablated = evaluate(model_ablated, X_test.drop(columns=features), y_test)
    
    ablation_results[f'without_{group_name}'] = score_ablated

# Report: "Removing historical features drops AUC by 15%, 
#          confirming their importance"

D. Robustness Analysis

# Test 1: Noise in flood reports (simulate crowdsourcing noise)
def add_location_noise(reports, noise_std_meters=100):
    """Simulate GPS inaccuracy in crowdsourced reports"""
    noisy = reports.copy()
    noisy['lat'] += np.random.normal(0, noise_std_meters/111000, len(reports))
    noisy['lon'] += np.random.normal(0, noise_std_meters/111000, len(reports))
    return noisy

# Test with increasing noise levels
for noise_level in [50, 100, 200, 500]:
    noisy_reports = add_location_noise(reports, noise_level)
    features_noisy = extract_features(noisy_reports)
    score_noisy = evaluate(model, features_noisy, y_test)
    print(f"Noise {noise_level}m: AUC = {score_noisy}")

# Test 2: Missing data
for missing_pct in [0.1, 0.2, 0.3]:
    X_missing = simulate_missing(X_test, missing_pct)
    score_missing = evaluate(model, X_missing, y_test)

E. Error Analysis (Kualitatif)

# Identify worst predictions
errors = abs(y_test - predictions)
worst_indices = errors.argsort()[-20:]  # Top 20 errors

# Manual analysis
error_analysis = []
for idx in worst_indices:
    segment = road_segments.iloc[idx]
    error_analysis.append({
        'segment_id': segment['id'],
        'predicted': predictions[idx],
        'actual': y_test[idx],
        'error': errors[idx],
        'features': X_test.iloc[idx].to_dict(),
        'possible_reason': ''  # Fill manually
    })

# Categorize errors
error_categories = {
    'elevation_limitation': 0,
    'missing_flood_reports': 0,
    'drainage_unknown': 0,
    'edge_case': 0,
    'data_error': 0
}
```

### Success Criteria (Honest & Achievable)

| Criterion | Threshold | Interpretation |
|-----------|-----------|----------------|
| AUC-ROC vs random baseline | > 0.70 | Model is meaningfully better than chance |
| AUC-ROC vs elevation-only | > +0.05 | Additional features provide value |
| ML vs rule-based improvement | > +0.03 or insight | Either improvement OR understanding why not |
| ECE (calibration) | < 0.15 | Confidence scores are trustworthy |
| Ablation: each component | Contributes > 0.02 | Every feature group is justified |
| Robustness: 100m noise | AUC drop < 0.05 | Model tolerates realistic data quality |

**Jika threshold tidak tercapai:**
Paper tetap valid dengan framing: "Analysis of challenges in vehicle-aware flood risk modeling" — similar to your Unicode obfuscation paper which focuses on failure analysis.

---

## 6. Revised 8-12 Week Roadmap

### Overview
```
Phase 1: Foundation (Week 1-2)
    └── Setup, data collection, exploration

Phase 2: Core Development (Week 3-6)
    └── Feature engineering, baseline, ML model

Phase 3: Analysis & Refinement (Week 7-9)
    └── Evaluation, uncertainty, error analysis

Phase 4: Delivery (Week 10-12)
    └── Dashboard, paper, documentation

Week-by-Week Detail

Week 1: Project Setup & Data Collection

Week 1 Deliverable:

• All core data downloaded
• Data dictionary complete
• Logbook entry #1

Week 2: Data Processing & Exploration

Week 2 Deliverable:

• Processed datasets ready
• EDA notebook with insights
• Preliminary data quality assessment

Week 3: Feature Engineering

Week 3 Deliverable:

• Complete feature matrix
• Feature engineering notebook
• Methodology draft (Feature Engineering section)

Week 4: Baseline Development

Week 4 Deliverable:

• 3 baseline models implemented
• Baseline evaluation notebook
• Performance comparison table

Week 5: ML Model Development

Week 5 Deliverable:

• Trained ML model(s)
• Model comparison with baselines
• Feature importance analysis

Week 6: Uncertainty Quantification

Week 6 Deliverable:

• Uncertainty quantification module
• Calibration analysis
• Confidence scores validated

Week 7: Comprehensive Evaluation

Week 7 Deliverable:

• Complete evaluation suite
• Ablation study results
• Robustness analysis

Week 8: Error Analysis & Insights

Week 8 Deliverable:

• Error analysis document
• Insights for paper Discussion section
• Honest limitations documented

Week 9: Dashboard Development (Part 1)

Week 9 Deliverable:

• Dashboard v0.5 (functional but not polished)
• Core interactive features working

Week 10: Dashboard Development (Part 2) & Paper Draft

Week 10 Deliverable:

• Complete dashboard v1.0
• Demo video
• Paper draft: Intro + Related Work

Week 11: Paper Writing (Main)

Week 11 Deliverable:

• Complete paper draft v1
• All figures and tables
• References formatted

Week 12: Revision & Finalization

Week 12 Deliverable:

• Final paper ready for submission
• Clean, documented GitHub repo
• All supplementary materials ready

Checkpoint Summary

Contingency Plans

7. Final Novelty Statement

Versi Paper-Ready (Abstract)

"This study develops FloodPass, a vehicle-aware flood risk assessment framework for urban road segments in Jakarta, Indonesia. Addressing the challenge of limited sensor infrastructure, we propose a methodology that derives flood exposure proxies from publicly available crowdsourced reports, elevation data, and historical patterns—without requiring real-time water level measurements. Unlike existing flood monitoring systems that provide uniform risk information, FloodPass differentiates risk assessments based on vehicle characteristics such as ground clearance, enabling more personalized decision support. We introduce uncertainty quantification through bootstrap estimation and probability calibration, allowing users to understand the confidence level of each risk assessment. Evaluated on a case study corridor in South Jakarta using data from 2020-2025, our approach demonstrates [X% improvement] over baseline methods while maintaining calibrated uncertainty estimates. This work contributes a practical, reproducible methodology for flood risk communication in cities with data constraints, along with an honest analysis of the challenges and limitations in this problem domain."

Breakdown Klaim yang Jujur

Apa yang Membuat Ini Layak Publikasi

1. Gap yang Diisi: Mayoritas flood monitoring systems adalah binary (ada banjir / tidak). Belum ada yang secara eksplisit memodelkan vehicle-specific risk di Indonesia.
2. Reproducibility: Semua data publik, kode akan di-open-source, metodologi terdokumentasi.
3. Honest Evaluation: Bukan hanya melaporkan angka tinggi, tapi juga ablation, robustness, error analysis, dan limitations.
4. Practical Relevance: Jakarta memiliki masalah banjir nyata, dan sistem ini bisa menjadi building block untuk solusi yang lebih lengkap.
5. Methodological Contribution: Pendekatan weak labeling dan uncertainty quantification untuk domain dengan data terbatas.

Summary: v2 → v2.1 Changes

Apakah ada bagian dari v2.1 ini yang perlu saya elaborasi lebih lanjut, Ricky? Atau ada constraint tambahan yang perlu dipertimbangkan sebelum kamu presentasikan ke Prof. Widodo?

Oke Ricky, santai. Aku jelasin dari nol pake bahasa paling sederhana.

FloodPass: Penjelasan Pake Bahasa Bayi 🍼

Masalah Sehari-hari yang Mau Diselesaikan

Situasi: Kamu lagi di jalan, hujan deras, terus lihat genangan air di depan.

Pertanyaan di kepala kamu:

"Gue lewat apa engga ya? Kalo nekat nyangkut gimana? Tapi kalo muter jauh banget..."

Masalahnya:

• Kalo pake motor → genangan 30cm udah bahaya
• Kalo pake mobil sedan → 30cm masih bisa (hati-hati)
• Kalo pake SUV/Fortuner → 30cm santai aja

Tapi kamu ga tau:

1. Ini airnya berapa cm sih?
2. Kendaraan gue kuat ga lewat sini?
3. Seberapa yakin gue sama tebakan gue?

Apa yang FloodPass Lakukan?

FloodPass = "Asisten yang kasih tau seberapa bahaya jalan ini buat kendaraan kamu"

Analoginya Gini:

Bayangin kamu punya temen yang:

• Hafal jalan-jalan mana yang sering banjir
• Tau motor sama mobil beda kemampuannya
• Jujur bilang "gue ga yakin sih, tapi kayaknya..."

FloodPass itu versi digitalnya.

Gimana Cara Kerjanya? (Super Simplified)

Step 1: Kumpulin Info Jalan

FloodPass tau tentang jalan-jalan di Jakarta:

• Ini jalan tinggi apa rendah? (dari data elevasi/ketinggian tanah)
• Jalan ini sering banjir ga? (dari laporan orang-orang di Petabencana)
• Tipe jalannya gimana? (jalan besar? gang kecil?)

Step 2: Kumpulin Info Kendaraan

FloodPass tau tentang kendaraan:

• Motor → "perut"-nya rendah (ground clearance ~15cm)
• Sedan → sedang (~17cm)
• SUV → tinggi (~25cm)

Step 3: Gabungin & Kasih Skor

JALAN + KENDARAAN = SKOR RISIKO

Contoh output:

📍 Jl. Kemang Raya

🏍️ Motor:     Risiko 8/10 (BAHAYA!)    → Yakin 70%
🚗 Sedan:     Risiko 6/10 (Hati-hati)  → Yakin 65%
🚙 SUV:       Risiko 3/10 (Aman)       → Yakin 60%

⚠️ Kenapa bahaya: Jalan ini rendah, sering banjir, 
   terakhir ada laporan banjir 2 minggu lalu

Bedanya Sama Sistem yang Udah Ada?

Pantau Banjir Jakarta (Yang Sekarang):

"Jl. Kemang Raya: Banjir 40cm"

Cuma kasih tau tinggi air. Kamu harus mikir sendiri: "40cm tuh bahaya ga buat motor gue?"

FloodPass (Yang Kamu Bikin):

"Jl. Kemang Raya: 
 - Buat motor kamu: BAHAYA (8/10)
 - Buat mobil kamu: Hati-hati (6/10)"

Langsung kasih tau bahaya apa engga untuk kendaraan spesifik kamu.

Data dari Mana?

Yang Dipake (Gratis & Legal):

Yang TIDAK Dipake:

• Sensor beneran di jalan (ga punya)
• CCTV (butuh izin ribet)
• Data rahasia pemerintah

Apa yang Kamu Bikin Konkretnya?

1. Dataset

Kumpulan data jalan + banjir + kendaraan yang udah dirapiin.

2. Model/Rumus

"Otak" yang bisa ngitung: jalan ini + kendaraan ini = risiko berapa

3. Dashboard (Website Sederhana)

Tampilan interaktif dimana orang bisa:

• Pilih lokasi
• Pilih kendaraan
• Liat skor risiko

4. Paper Ilmiah

Tulisan akademis yang jelasin cara kerja + hasil eksperimen.

Contoh Pemakaian (Skenario)

Skenario: Budi Mau Pulang Kerja

Situasi:

• Budi di Sudirman, mau pulang ke Kemang
• Lagi hujan deras
• Budi naik motor

Tanpa FloodPass:

Budi: "Yaudah gas aja, paling ga dalam-dalam amat" Motor nyangkut, mesin mati, Budi nangis

Dengan FloodPass:

Budi buka app, cek Jl. Kemang App: "Buat motor: Risiko 8/10 (BAHAYA!) - Confidence 70%" Budi: "Oh shit, mending gue lewat jalan lain atau nunggu reda deh"

Kenapa Ini "Research" dan Bukan Cuma "Bikin App"?

Karena ada pertanyaan ilmiah yang dijawab:

RQ1: Gimana caranya nebak bahaya banjir TANPA sensor langsung di jalan? → Pake data laporan orang + ketinggian tanah sebagai "proxy"

RQ2: Apakah bedain per kendaraan bikin hasilnya lebih berguna? → Eksperimen: model yang bedain kendaraan vs yang ga bedain

RQ3: Gimana caranya jujur soal ketidakpastian? → Kasih "confidence score" biar orang tau ini tebakan seberapa yakin

Batasan yang Harus Jujur Diakui

FloodPass BUKAN:

• ❌ GPS real-time yang update tiap detik
• ❌ Jaminan 100% akurat
• ❌ Izin resmi buat lewat atau engga
• ❌ Pengganti info dari BPBD/polisi

FloodPass ADALAH:

• ✅ Alat bantu mikir
• ✅ Informasi tambahan buat pertimbangan
• ✅ Riset/eksperimen akademis

Disclaimer wajib:

"Ini cuma alat bantu. Keputusan tetap di tangan kamu. Kalo ragu, jangan lewat."

Timeline Singkat (12 Minggu)

Kesimpulan: FloodPass dalam 1 Kalimat

"FloodPass adalah sistem yang kasih tau kamu seberapa bahaya suatu jalan banjir untuk kendaraan spesifik kamu, berdasarkan data publik, sambil jujur soal seberapa yakin sistemnya."

Analogi Final 🎯

Pantau Banjir = Rambu yang bilang "Ada Banjir 40cm"

FloodPass = Temen yang bilang "Bro, jalan itu banjir. Motor lo pendek, bahaya. Tapi kalo lo bawa Fortuner nyokap, masih aman sih kayaknya. Tapi gue juga ga 100% yakin ya, soalnya gue ga di sana langsung."

Udah lebih paham, Ricky? Ada bagian yang masih bingung?